One of the claims for object-oriented programming is that it makes it easier for software to model real-life business situation. The new vision of computing is of distributed Business Objects existing as independently developed executables or binaries, which can be redeployed as self-contained units anywhere in a network, and on any platform. Businesses are finding that encapsulating business logic into Business Objects provides insufficient additional flexibility over that provided by procedural-based applications.
Although the term Business Object has been in widespread use, no formal definition existed until the Object Management Group's (OMG) Business Object Management Special Group (BOMSIG) took the task of developing a consensus meaning for the term. Business Objects are representations of the nature and behavior of real world things or concepts in terms that are meaningful to the business. Customers, products, orders, employees, trades, financial instruments, shipping containers and vehicles are all examples of real-world concepts or things that could be represented by Business Objects. Business Objects add value over other representations by providing a way of managing complexity, giving a higher level perspective, and packaging the essential characteristics of business concepts more completely. We can think of Business Objects as actors, role-players, or surrogates for the real world things or concepts that they represent.
Implementing business rules within Business Objects enables businesses to automate their policies and practices. For example, business rules can control the flow through the tasks of a business process. The next task is performed only when the rules that permit ending the previous task and those that determine that the next task should be entered have been satisfied. Business rules can also assist in decision-making and have a significant impact on decision support applications. For example, a rule system can determine whether or not to extend credit to a customer and how much credit to extend.
Historically, business rules have been embedded within the logic of applications. These applications have been designed to perform business functions, horizontal applications such as accounts receivable and inventory control or vertical applications such as portfolio analysis in financial services and insurance eligibility in healthcare. Developers have built these systems without explicit regard for business rules. As a result, when business policies and practices change--and they're constantly changing--it's difficult to reflect those changes in the applications that implement them.
More recently, business rules have been implemented in database triggers. In response to database changes, database triggers are automatically invoked by a database server. The code in the triggers could execute some procedural logic as well as manipulate the database. Database triggers and stored procedures offer the advantage of modularity. They isolate business rules and technical data-manipulation rules from application logic. Triggers automate business rules processing and provide application independence (any application changing the database causes the triggers to be fired). However, triggers also have some serious disadvantages. They are hard to develop. They are intended to implement technical data-manipulation rules as well as business rules, and they are hard to maintain and extend.
Database triggers are frequently expressed in the dialect of the databases in which they're to be implemented. These languages are frequently proprietary and complex. Development is a text-editing task. There are few, if any, visual tools to assist developers in specifying trigger code.
Database triggers function on the elements and values of a database. Their specification is far more technically oriented then business oriented. Some triggers implement business rules, but many implement and enforce data integrity and data consistency. Applications builders who are using a trigger built by another developer might have difficult deducing the business rules implemented by the trigger by looking at trigger code. Business analyst, the individuals who should be responsible for business rules specification, frequently find the triggers hard to learn.
Database triggers are also hard to maintain. Developers may find it difficult to change triggers in response to business changes. None of these database languages are object-oriented. Trigger development rarely follows the rigors and formality of large-scale application development. As a result, triggers tend to be monolithic and hard to understand.
More recently, object-oriented business rules technologies have evolved which allow rules to route work through the tasks of a business process, where reasoning can be applied to complex decision-making, and where knowledge systems can perform operator assistance.
Object-oriented business rules technologies base rule processing on an application's object model or component model. Some products based on these technologies use inferencing techniques on an application's object model to create, delete, and manipulate variables and objects and to determine their values. Other products utilize a technique which always fire a rule before or after an object method. Both of these techniques are very programmer intensive, as they are built right into the objects themselves.
Business rules are different from Business Objects. Business Objects represent business entities like customers, products, and orders. They encapsulate the data and behavior needed to perform business functions. Business rules implement the policies and practices of an organization. They control the ways that Business Objects perform business functions. An example will demonstrate the differences. For order processing, an application uses customer, product, and order Business Objects. While orders are processed, values for customer credit limits and inventory restock levels come into play. An organization may embed these values within the Business Object. But using business rules to determine these values would be more effective because business rules separate business policies from application processing. The business policies can be easily changed to reflect dynamic business changes. A credit limit may depend on factors including current receivables, credit history, time of year, product demand, product life cycle, creditor's business stability, and so on. Most Business Objects would have a hard-coded value for credit limit. Business rules can "reason" a value based on complex and timely criteria. Business rules can make a business more adaptable to business changes, more responsive to its customers, and more responsible to its stockholders.
Object-oriented technologies give business rules tremendous power and flexibility. Rules may be applied to a broad range of application resources. Individual rules may specify multiple conditions, and developers may specify complex relationships among the conditions. Systems of rules may be executed to "reason" a complex decision. And the technologies use backward chaining and/or forward chaining to iteratively and recursively evaluate rules.
The disadvantage of object-oriented business rules technologies is the traditional trade-off of power and flexibility--complexity. Use of these technologies requires skills in object-oriented design and object-oriented development. Specific products are built on proprietary and idiosyncratic object models and use proprietary languages for business rule specification.
Consequently, it would be desirable to provide a procedure for externalizing business decisions into business rules which are described and manipulated by business experts instead of programmers.